Promotion packaging transmission groups

ABSTRACT

Embodiments of the invention relate to routing promotion content files to groups of end node devices having the same or similar device attributes, such as data storage capacity, called transmission groups. Specifically, a promotion is assembled into one or more data packages, with a package being created for each different transmission group. Promotions may be aggregated, with multiple promotions being placed in each package. The packages may include information such as promotion identification, start time, end time, duration, port number, multicast or broadcast address to facilitate bulk data routing via broadcast or multicast. The packages are then used to generate and deliver promotion schedules to each device of a transmission group and to schedule bulk data transmissions to the respective transmission groups via separate broadcast or multicast for each package.

RELATED APPLICATION(S)

This application is a continuation of U.S. application Ser. No.09/969,513, filed Oct. 2, 2001, which claims benefit of U.S. ProvisionalApplication No. 60/253,489, filed on Nov. 28, 2000. The entire teachingsof the above application(s) are incorporated herein by reference.

BACKGROUND OF THE INVENTION

At the present time, most data network devices located in the residencesinclude some type of personal computer. Typically, these personalcomputers are used to connect to Internet Service Providers over dial-upconnections to execute application programs such as email clients andWeb browsers that utilize the global Internet to access text and graphiccontent. Increasingly, the demand is for multimedia content, includingaudio and video, to be delivered over such networks. However, thebackbone architectures of purely data networks, especially thosedesigned for use with the telephone network, were not originallydesigned to handle such high data rates.

The trend is towards a more ubiquitous model where the network devicesin the home will be embedded systems designed for a particular functionor purpose. This has already occurred to some degree. Today, forexample, cable television (CATV) network set-top boxes typically havelimited data communication capabilities. The main function of the datadevices is to handle channel access between residential users and a headend or server on the cable TV network.

However, it is estimated that the worldwide market for Internetappliances such as digital set-top boxes and Web-connected terminalswill reach $17.8 billion in 2004, and millions of such digital set-topboxes have already been deployed. Increasingly, advertisers and contentproviders view the cable set-top as the first platform of choice forwidespread delivery of a suite of intelligent content management anddistribution services.

In the future, the functionality offered by these set-top boxes or otherembedded platforms, such as a game system, will be expanded. Forexample, they may offer Internet browsing capabilities and e-commerceserving capabilities. Moreover, it is anticipated that common-householdappliances will also have network functionality, in which they will beattached to the network to automate various tasks.

SUMMARY OF THE INVENTION

Because of the extremely large numbers of network devices in suchnetworks, efficient distribution and delivery of promotions and otherdigital content remains a challenge. Where the personal computer can beupdated with new network drivers as the network evolves, embedded clientsystems remain relatively static. In addition, such networks may havehundreds of thousands, if not millions, of network devices to manage. Itis evident that standard data Open Systems Inerconnection (OSI) layerednetwork protocols, which were optimized for peer to peer communication,are not an entirely acceptable arrangement.

Consider that the digital set top box provides certain interestingfunctionality, such as the ability to store certain amounts of data. Theset top box can thus be designed to store a multimedia computer filewhich represents a digitized version of a promotion. However, such anetwork may have hundreds of thousands, if not millions of set topboxes, to which delivery of promotions must be individually coordinated.If such a data network were built using only the standard protocols suchas direct TCP/IP messaging from a central promotion server to the settop boxes, the sheer volume of message traffic needed to route thepromotions to the intended destinations would quickly overload thecentral data server.

An additional difficulty is encountered with the fact that set top boxesin a typical cable television network are not of a uniform model numberor even made by the same manufacturer. Thus, there typically is adisparity of functionality in different set top boxes which are toreceive a given promotion. This creates an additional promotionmanagement problem in that certain set top boxes may have ample memorycapacity, allowing them to receive more promotions at a given time,while other devices may have limited memory capacity, requiring lesspromotions to be sent to them.

Embodiments of the invention relate to routing promotion content filesto groups of end node devices having the same or similar deviceattributes (e.g., data storage capacity) called transmission groups.Specifically, a promotion is assembled into one or more data packages,with a package being created for each different transmission group.Promotions may be aggregated, with multiple promotions being placed ineach package. The packages may include information such as promotionidentification, start time, end time, duration, port number, multicastor broadcast address to facilitate bulk data routing via broadcast ormulticast. The packages are then used to generate and deliver promotionschedules to each device of a transmission group and to schedule bulkdata transmissions to the respective transmission groups via separatebroadcast or multicast for each package.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating a multimedia content delivery systemfor distributing content such as targeted promotions according to oneembodiment of the present invention.

FIG. 2 is a diagram of a set top box/video display system displayingactive promotions according to one embodiment.

FIG. 3A is a diagram illustrating a set of packages according to oneembodiment.

FIGS. 3B and 3C is a table containing typical data transmissionparameters specified by a package according to one embodiment.

FIG. 3D is a table containing parameters specified by a transmissiongroup according to one embodiment.

FIG. 3E is a flow diagram illustrating a process for packagingpromotions for transmission groups according to one embodiment.

FIG. 3F is a diagram illustrating one way in which devices may be mappedfrom their a promotion group into transmission groups.

FIG. 4A is a time line diagram illustrating a promotion transmissionlead-time with its constituent lead-times according to one embodiment.

FIG. 4B is a time line diagram illustrating a schedule transmissionlead-time according to one embodiment.

FIG. 5 is a state line diagram illustrating a process for synchronizingthe delivery of promotions to end node devices according to oneembodiment.

FIG. 6A is a table identifying the parameters of a local monikeraccording to one embodiment.

FIG. 6B is a table identifying the parameters of a remote monikeraccording to one embodiment.

FIG. 7 is a flow diagram illustrating a process for generatingtransmission schedules for devices according to one embodiment.

FIG. 8 is a flow diagram illustrating a process of generatingtransmission requests according to one embodiment.

FIG. 9 is a table illustrating the parameters of a transmission requestaccording to one embodiment.

FIGS. 10A-10F illustrate the organization of tables of record within thedatabase according to one embodiment.

The foregoing and other objects, features and advantages of theinvention will be apparent from the following more particulardescription of preferred embodiments of the invention, as illustrated inthe accompanying drawings in which like reference characters refer tothe same parts throughout the different views. The drawings are notnecessarily to scale, emphasis instead being placed upon illustratingthe principles of the invention.

DETAILED DESCRIPTION OF THE INVENTION

Turning attention now to the drawings, FIG. 1 illustrates a multimediacontent delivery system for distributing content such as targetedpromotions according to one embodiment of the present invention.Embodiments of the multimedia content delivery system allow advertisersand service providers the ability to effectively utilize a multimedianetwork for targeting promotions or other content at consumers throughnetwork devices. In particular, the system facilitates the targeting ofpromotions in varying degrees of granularity from individuals to entiremarket segments. The system includes a large number of set top boxes ornetwork devices 10 connected to respective video displays 20, such astelevisions.

Promotions 30 typically include promotional content that may bepresented in various multimedia formats including standard audio visualclips, but also computer graphics, icons, or Hypertext Markup Language(HTML) content. Promotions are used to advertise goods and services,promote events, or present other commercial or non-commercialinformation. One or more promotions 30 may be simultaneously activewithin the video displays 20 and may be displayed in different ways. Forexample, in FIG. 2, promotions 30 are presented on electronic programguides, channel information bars 40, or overlaying video broadcastprogramming. Some active promotions that may be displayed on digital settop boxes allow user interaction such as linking to e-commerce web-sitesvia hyperlink connections or direct communication to a promotion serversubsystem to obtain additional software, such as device drivers, videogames, or other application software.

Referring back to FIG. 1, the multimedia content delivery system alsoincludes a promotion server subsystem 200 located at a data center and apromotion agent subsystem 300 embedded within each of the networkdevices. The promotion server subsystem 200 and the promotion agentsubsystems 300 communicate with each other through a combination ofapplication-level messaging and serialized bulk data transmissions.

The promotion server subsystem 200 periodically collects viewer usagedata from the promotion agent subsystem 300 of each of the multimediacontent viewing devices to generate viewership profiles. In televisionnetworks, the data collected by the promotion server subsystem 200 mayinclude tuner data (i.e., a history of channels watched) and responsesto past promotions. This history is kept on a relatively fine timescale, such as five seconds. In this way, it can be determined how longa particular promotion was deployed, or even which portions of apromotion or video program were viewed.

Regarding promotion delivery, the promotion server subsystem 200includes a database server 210, a promotion manager server 220, one ormore bulk data servers 230, a promotion manager client 240, a life-cyclemanager server 240, and a bank of routers 250-1, 250-2, . . . , 250-n.These components are typically located at a central location in themultimedia network at a data center, at a head end, or divided betweenthe two depending on the density and population of devices. It should beunderstood that these components may share physical platforms or bedistributed across multiple machines located at different places in thenetwork. For scalability reasons, a promotion scheduling process in thepromotion manager server 220 may be separated from a function which isresponsible for delivering promotion packages to the network devices 10.The delivery function may be instantiated on multiple machines, forexample, to provide better scalability, such as having one bulk dataserver per head end in the network. The life cycle manager 240 may alsobe instantiated separately for each router 250.

The routers 250 communicate with the network devices 10 through a datanetwork 75 which may itself include a further hierarchy of routers andbulk servers (not shown in FIG. 1). Ultimately, each of the networkdevices is connected to the network 75 through a head end location 50.In a typical cable television network, there may be many thousands ofnetwork devices connected to a particular head end, and there may bemany thousands of head ends 50.

To determine how to deliver targeted promotions to the network devices,the life-cycle manager server 240 of the promotion server subsystem 200first generates viewership profiles for each of the multimedia contentviewing devices from the collected data using a variety of statisticalmodels. The viewership profiles are then used to associate groups ofnetwork devices with a given target promotion.

Promotion groups are collections of multimedia content viewing deviceswhose individual viewership profiles match membership criteriadescribing a particular demographic or viewership history. For example,a promotion group may be demographically based, (i.e., married women intheir 30's with more than one school age child and a household income ofat least $100,0000), or based on viewership history, (i.e., tends towatch the Golf Channel on Sunday afternoon). Therefore, the promotionserver subsystem 200 is adaptable to changes in viewer usage orviewership patterns by making adjustments to promotion groups.Viewership profiles and promotion groups are described in more detail inU.S. Patent Application Attorney Docket Number 2657.2003-000, entitled“Using Viewership Profiles to Target Advertisements” filed on the samedate herewith.

Promotions are then scheduled for delivery to specific promotion groups.A promotion is scheduled for delivery to a promotion group by anadvertiser or service provider entering a scheduling request for apromotion such as via a promotion manager interface client 225. Aspromotions are scheduled, the promotion manager server 220 adds orremoves promotion groups and/or scheduling information to promotions.This causes the creation or modification promotion delivery packages viastored data functions or procedures in the database 210. Later, thepackage information is read from the database 210 and used to createcustomized transmission schedules that specify when and how each of thenetwork devices 10 is to receive it.

The promotion agent subsystem 300 embedded in each of the networkdevices 10 includes a promotion agent 310 and a bulk data agent 320.Upon receipt of the transmission schedule messages, the promotion agent310 processes each schedule entry forwarding promotion download requeststo the bulk data agent 320 to receive each promotion identified in thetransmission schedule. The bulk data agent 320 handles the reception ofthe promotions from the scheduled data transmission as specified in thepromotion download requests. For example, in one embodiment, the bulkdata agent 320 tunes into a multicast data transmission stream at aspecified time and channel or network address specified in thetransmission schedule.

To initiate a transmission of promotion packages, the promotion managerserver 220 extracts a set of promotion packages from the database 210and converts each into a transmission request that is sent to one ormore of the bulk data servers 230. The bulk data server 230 fetches thepromotions from the database 210 that are identified in the transmissionrequest message, and transmits them via multicast or broadcasttransmission. The decision to broadcast or multicasts depends on whichis supported between the head end and the capabilities of the end nodedevices.

Once the promotions have been successfully delivered, the promotions areactivated at the network viewing devices as specified in promotioncontrol data of the transmission schedules. Promotion activation may beevent, time, or channel driven.

Packaging Promotions for Transmission Groups

Promotions may be scheduled for promotion groups that include diversetypes of end node devices. For example, a promotion group may includedevices that are functionally different, such as television set topboxes and Internet video phones. Even functionally similar types ofdevices (e.g., set top boxes) may differ with respect to certainphysical and functional device attributes. Such attributes may includedata storage capacity and the ability to receive multicast transmissionsusing standard data protocols, such as Transmission Control Protocol orUniversal Data Protocol over Internet Protocol (TCP/IP or UDP/IP)networks. Device attributes have a direct effect on the manner in whichpromotions and other content are actually delivered to devices oftargeted promotion groups. For example, devices with less data storagecapacity are not able to cache as many promotions as devices with morestorage capacity. The promotion server subsystem 200 adapts the deliveryof promotions to the attributes of different device types within apromotion group through the use of packages.

FIG. 3A is a diagram illustrating a set of packages according to oneembodiment. A package is a data object 600 containing a set ofpromotions 610 and data transmission parameters 620 that specify thetime and/or manner of delivery for a set of promotions to a particulartransmission group. Transmission groups are sets of end node devicessharing common device attributes, such as storage and resourcelimitations. For example, set top boxes of a particular model number maybe considered to be part of the same transmission group. Devices may beinitially assigned to a transmission group manually, or automatically,during an automated registration process in which device attributes arediscovered.

FIGS. 3B and 3C is a table containing typical data transmissionparameters specified by a package according to one embodiment. Suchparameters include data rates, data transmission times, and routingaddresses, such multicast or broadcast port addresses.

Furthermore, a package includes a TRANSMISSION_GROUP_ID parameter thatidentifies the transmission group which is to receive the package. FIG.3D is a table containing parameters specified by a transmission groupaccording to one embodiment. The parameters of a transmission group addto or affect the data transmission parameters of the package. Forexample, the size of a package is determined by the maximum package sizeparameter of a transmission group.

When a promotion is scheduled, the scheduling process determinesTRANSMISSION_GROUP_ID by mapping promotion group identifiers intotransmission group identifiers. In the preferred embodiment, all of thepromotions within a single package share a common transmission groupidentifier. When a promotion is associated with more than onetransmission group, a separate package is created in the system for eachgroup.

FIG. 3E is a flow diagram illustrating a process for packagingpromotions for transmission groups according to one embodiment.

In step 410, a promotion is scheduled for delivery to one or morepromotion groups where each of the promotion groups includes a set ofend node devices. In particular, an advertiser or service providerenters a promotion schedule request into the promotion server subsystem200 through the promotion manager client 225. In one embodiment, thepromotion schedule request identifies a promotion, a recipient of thepromotion (i.e. promotion group), as well as promotion schedulinginformation (e.g., channel time slot information containing start times,trigger events, or other such criteria for promotion activation).

The promotion manager server 220, in turn, places database functioncalls that add the promotion, recipients, and scheduling information tothe database 210. As an indirect result of the promotion manager server220 adding/removing recipients to promotions and adding/removingscheduling information for promotions, packages are created or modified.According to one embodiment, the creation and modification of packagesis handled by a set of stored database procedures internal to thedatabase 210 starting at step 420.

In step 420, the set of end node devices included in the promotion groupis subdivided into one or more transmission groups. According to oneembodiment, the promotion group is resolved into transmission groups byan internal database query resulting in a list of unique transmissiongroup identifiers corresponding to the various types of end node deviceswithin the promotion group. FIG. 3F is a diagram illustrating one way inwhich devices may be mapped from their promotion group into transmissiongroups. Each of the resulting transmission groups 510 and 520 includes amutually exclusive set of devices from the promotion group. Packagesthen must be created and/or appended to for each of the transmissiongroups which is to receive the promotion.

Referring back to FIG. 3E, a determination is made whether or not apackage has been created for a transmission group in step 430. Accordingto one embodiment, this involves an internal database query for apackage indexed by the unique identifier for the transmission group.

If there is no package associated with a transmission group, a newpackage is created for the transmission group in step 440. The creationof a package involves creating a new package record within the database210. The data transmission parameters of the package record illustratedin FIGS. 3B and 3C are adapted to the device attributes of thetransmission group. The record is maintained in the database 210 withina table of other package records.

In more detail regarding adapting packages to transmission groups, oneattribute of network devices of the same transmission group may includedata storage capacity. The data storage capacity may be an expectedamount or percentage of available cache memory in the set top box.Alternatively, the data storage capacity may be an expected amount orpercentage of data storage dedicated solely for caching promotions.Network providers in cable networks typically restrict data storageavailable for dedicated functionality, such as promotion caching.

Accordingly, the package may be adapted with a maximum package size lessthan or equal to the data storage capacity available for the specificend node devices which are members of the present transmission group.The maximum package size, therefore, limits the number and size ofpromotions that can be delivered to a transmission group. The maximumpackage size may be different among packages for transmission groupsranging from small to large package sizes. The maximum package sizeensures that an optimal number and size of promotions are delivered todevices within a transmission group.

In another preferred embodiment, the common device attributesaccommodated by the package may also include data processor speed.Faster data processors are able to handle higher data transmission ratesas opposed to slower processors. A package may be adapted to accommodatethe data processor speed for a transmission group by specifying anappropriate data transmission rate, which throttles the rate at whichdata is transmitted to devices so as not to cause packet overrun on theembedded client. Data overrun typically occurs when a device dataprocessor cannot handle the amount of data being received from thenetwork. The data transmission rate is the number of ticks per networkpacket during transmission. A network packet is about 640 bytes and atick is approximately 1×10-7 seconds.

Referring to step 450, if a package is already created for atransmission group, the promotion manager server 220 determines whetherthere is sufficient space to add the scheduled promotion based on itsmaximum package size. Promotions are added to each package unless themaximum package size would be surpassed. Therefore, if there isinsufficient space for the addition of the promotion, a new package iscreated for the transmission group as specified in step 440.

Once a package is either created or located within the database 210having sufficient space, the promotion is added to the package in step460. Promotions may be added to packages containing promotions fordifferent promotion groups. In one embodiment, promotions are added topackages by creating a record in the database 210 that correlates apromotion identifier with a package identifier and storing the record ina corresponding table entry.

Precasting Promotions in a Multimedia Network

In addition to specifying the manner of transmitting promotion packages,packages may also specify the timing of promotion delivery totransmission groups. As illustrated in FIG. 3B, each package specifies apackage start time (i.e., PACKAGE_START_TIME) corresponding to theearliest promotion start time for its set of promotions. As promotionsare added to a package, the package start time is updated using thestart time of the earliest promotion in the package.

According to a preferred embodiment of the present invention, a packageof promotions is sent in advance of, or “precast” to a transmissiongroup at a data transmission time which is prior to the package starttime to ensure that the promotions will be activated as scheduled.

Optimally, the data transmission time should be far in advance of thepackage start times, particularly at a time of low network bandwidthutilization such as in the early pre-dawn hours of the day. However, dueto certain device constraints, in particular data storage capacity,packages destined for transmission groups having low data storagecapacity must be delivered closer to the package start time. Otherwise,there is a risk that promotions from subsequent packages may overwritepromotions that were previously cached but have not yet expired.

The promotion delivery system therefore optimally precasts packages ofpromotions by accounting for the data storage capacity and other commondevice attributes of a transmission group. The process results inpackages of promotions being transmitted at appropriate datatransmission times preventing data loss and utilizing the availablenetwork bandwidth more efficiently.

In brief overview, the process for determining the data transmissiontime for a package of promotions involves (1) determining a packagetransmission lead-time from the common device attributes of atransmission group; (2) determining a data transmission time bysubtracting the package transmission lead-time from the package starttime; and (3) initiating the transmission of the promotion package tothe transmission group at the data transmission time.

FIG. 4A is a time line diagram illustrating considerations fordetermining a package transmission lead-time with its constituentlead-times according to one embodiment. Each of the constituentlead-times relates to a common device attribute of the transmissiongroup to which the package corresponds. The package transmissionlead-time 700 typically includes a storage dependent lead-time ΔT₁, adata transit lead-time ΔT2, a network latency lead-time ΔT₃, and a loadfactor lead-time ΔT₄.

According to one embodiment, the data storage capacity of a transmissiongroup is a device attribute for determining the package transmissionlead-time. Device storage capacity is accounted for in astorage-dependent lead-time ΔT₁ which is a variable time period directlyrelated to the data storage capacity of a transmission group.

Transmission groups having low storage capacity need promotion contentcached in its devices closer to the time of promotion activation.Otherwise, there is a risk that the promotion content may be overwrittenby promotions from subsequent packages, prior to the scheduled time foractivation of the stored promotion. Therefore, if the device datastorage capacity is low, the storage-dependent lead-time ΔT₁ isrelatively short, being closer to the package start time. Shortstorage-dependent lead-times typically range from seconds to minutes.

Conversely, transmission groups having high data storage capacity havethe necessary cache resources to store more promotions. This allowspromotion content to be received at an earlier time when expectednetwork bandwidth utilization is low. Therefore, the storage-dependentlead-time ΔT₁ is relatively long for the transmission groups which havehigh data storage capacity, optimally falling within a period ofexpected low bandwidth utilization of the multimedia network. Longstorage-dependent lead-times typically range from hours to days.According to one embodiment, the storage-dependent lead-time ΔT₁ isstored in the database 210 as a transmission group parameter (i.e.,DATA_TX_LEADTIME) of FIG. 3D. 5 By way of example, assume that a set ofpromotions is targeted for a promotion group having two transmissiongroups. One group corresponds to devices having a low storage capacityattribute, while the other is associated with a high storage capacityattribute. Packages are created containing the promotions and having thesame package start time for each group. However, the package ofpromotions for the transmission group having a high storage capacitywould have an earlier data transmission time (e.g., one day in advanceof package start time at 3:00 AM) as opposed to the transmission grouphaving less storage capacity (e.g., 5 minutes prior to package starttime). Thus, by precasting the packages at different data transmissiontimes, allocation of network bandwidth is more efficiently distributedfor promotion delivery among the transmission groups.

According to another embodiment, the device processor speed of atransmission group is another device attribute for determining thepackage transmission lead-time 700. Since device processor speeds varybetween manufacturers and device models, the processor speed of atransmission group is accommodated by a data transmission rate for apromotion package. Accordingly, the data transit lead-time ΔT₂ accountsfor the time period necessary to transmit the entire package ofpromotions to a transmission group. The data transit lead-time ΔT₂ iscalculated by multiplying the (1) inverse of the data transmission rate,(2) sum total of the set of promotion sizes, and (3) cycle count. Thecycle count is the number of times the data transmission is repeated.Repetition allows devices that started to receive promotions late toretrieve what it may have previously missed.

According to a further embodiment, network latency is a common deviceattribute for determining the package transmission lead-time 700.Although devices may be similar in terms of manufacturer and model, thenetwork topology, to which such devices are connected, can affect thetiming of promotion delivery. Where network latency is a factor, suchdevices are typically grouped together in a separate transmission groupstatically accounting for such network latency delays.

For example, a transmission group of devices that are connected to asatellite network are typically slower than a transmission group ofdevices connected to a cable television network. A network latencylead-time ΔT₃ is a variable time period that may be directly related tothe network delays attributed to the particular network topology for atransmission group. The network latency lead-time ΔT₃ is relatively longif the network latency associated with a particular network topology istypically high. Conversely, the network latency lead-time ΔT₃ isrelatively short if the network latency is at most nominal.

Alternatively, the network latency lead-time ΔT₃ may be determineddynamically by network statistics accumulated by the promotion managerserver 220. For example, as the promotion manager server 220 deliversmessages to devices, it can keep track of how long it took foracknowledgment messages to be returned from devices on various subnetsor head ends of the multimedia network. The network latency lead-timeΔT₃ may be dynamically adjusted to account for network delays attributedto network congestion.

Another factor that determines the package transmission lead-time is theserver load factor which affects the performance of the promotionmanager server 220. If the load on the promotion manager server 220causes the scheduling process to slow down, then there is a risk thatthe promotions may not be delivered at the specified data transmissiontimes, particularly with transmission groups having low data storagecapacity. Therefore, in order to account for the server load factor, aload factor lead-time ΔT₄ is added to the package transmission lead-time700. The load factor lead-time ΔT₄ is a variable time period thatadjusts to the statistics associated with server performance.

The promotion manager server 220 monitors its own performance by keepingtrack of how long certain tasks take to perform. For example, thepromotion manager server 220 may track performance statistics relatingto the processing of packages or the return of acknowledgment messagesfrom other processes in the promotion server subsystem 200. Suchstatistics provide an indication of server performance.

If the statistics indicate that server performance is slow, the loadfactor lead-time ΔT₄ is increased by an amount to account for the serverdelays in excess of the average data processing times. Conversely, ifthe statistics indicate that server performance is average or better,the load factor lead-time ΔT₄ may by decreased by a nominal amount if atall.

The data transmission time is subsequently calculated by adding up theconstituent lead-times of the package transmission lead-time 700 andsubtracting the resulting time period from the package start time. Theresulting data transmission time is the time when the multicast orbroadcast transmission of promotions must start. According to oneembodiment, the data transmission time is stored as a parameter,DATA_TX_TIME, of a package as illustrated in FIG. 3B

In addition to determining data transmission times for promotionpackages, the promotion manager server 220 determines a scheduletransmission time for sending transmission schedule messages to end nodedevices of targeted promotion groups. Transmission schedules are used tosynchronize the delivery of promotions between the promotion serversubsystem 200 and devices of targeted promotion groups. The schedulestypically contain information relating to the time and manner ofpromotion delivery and are customized for each end node device. Thegeneration of transmission schedules and their use are discussed in moredetail with reference to FIG. 5 and FIG. 7.

The schedule transmission time is a calculated time when thetransmission schedules are to be delivered to the targeted end nodedevices. It is typically determined by subtracting a scheduletransmission lead-time ΔT₅ from the data transmission time for a packageof promotions.

FIG. 4B is a time line diagram illustrating a schedule transmissionlead-time according to one embodiment. The schedule transmissionlead-time ΔT₅ is typically a fixed time period. The fixed time periodshould be long enough to allow for the delivery of a schedule message toa device and for the return of an acknowledgment message back (e.g., 120seconds). Preferably, the fixed time period should allow for multipledeliveries and acknowledgments of schedule messages prior to the datatransmission time for the instances where initial delivery attemptsfail. The schedule transmission time is determined by subtracting theschedule transmission lead-time ΔT₅ from the data transmission timeDATA_TX_TIME. According to one embodiment, the schedule transmissiontime is stored as a parameter, INFO_TX_TIME, of a package as illustratedin FIG. 3B

As additional promotions are added or removed, affected packages areautomatically adjusted, provided the transmission schedules have notbeen previously transmitted. Packages can only be changed manually oncethe transmission schedule has been sent, since any changes may involvere-transmitting the schedule to the devices.

Synchronization of Bulk Data Transfers

Once packages of promotions have been created, the promotion deliverysystem provides an efficient way of delivering these packages to devicesof targeted promotion groups. Due to the potential large number ofdevices, it is not efficient to deliver promotions individually to eachdevice. Likewise, broadcast transmissions of promotions unnecessarilyinterrupt devices that are not targeted for promotions in addition tothose that are. Therefore, the promotion delivery system deliverspromotions by synchronizing end node devices of targeted promotiongroups with multicast transmissions of promotion content.

In brief overview, the process involves (1) scheduling transmissions ofpromotion packages for delivery across multiple media; (2) notifyingdevices of targeted promotion groups of the scheduled bulk datatransmissions; (3) transmitting the packages of promotions via multicastor broadcast transmission; and (4) selectively receiving a subset of thepromotions during the scheduled transmissions. This process is notlimited solely to promotions, but can be modified to handle other typesof content as well, such as software applications, drivers, and otherdata files.

FIG. 5 is a state line diagram illustrating a process for synchronizingthe delivery of promotions to end node devices according to oneembodiment.

In step 800, the promotion manager server 220 obtains a set of promotionpackages from the promotion database 210. Packages are selected in orderaccording to their package start times from earliest to latest.

In step 810, the promotion manager server 220 schedules multicasttransmissions of promotions by generating customized transmissionschedules for each targeted end node device from the set of selectedpromotion packages. The transmission schedules identify the promotioncontent to be received, how and when the content will be delivered, andcriteria for activating the promotion. The process for generatingtransmission schedules is discussed in more detail with respect to FIG.7. According to one embodiment, the times specified in the transmissionschedules are synchronized with a time server on the multimedia networkor, in the case of television networks, may be synchronized with thebroadcast television programming.

In step 820, the promotion manager server 220 notifies all devices oftargeted promotion groups of the scheduled transmissions by sending thetransmission schedules individually as messages to the promotion agent310 of each of the end node devices 300. Since transmission schedulesare reliably delivered as messages, the promotion manager server 220 isable to track which devices have received their schedules and those thathave not.

In general, all messages, including schedule messages, are deliveredover a message routing subsystem. The message routing subsystem is anapplication level system involving the message routers 250-n such thatcommunication between the promotion server subsystem 200 and promotionagent subsystems 300 embedded within end node devices is facilitatedregardless of server platform.

In step 830, the promotion agent 310 processes the transmissionschedules converting them into promotion download request messages. Thepromotion download request messages direct the bulk data agent 320 toreceive data and the manner of doing so. The payload of the promotiondownload request message typically contains a serialized local monikerand a serialized remote moniker.

FIG. 6A is a table identifying the parameters of a local monikeraccording to one embodiment. The local moniker specifies where to cachepromotions in the device once the promotions are received (e.g., filepath or registry subkey).

FIG. 6B is a table identifying the parameters of a remote monikeraccording to one embodiment. The remote moniker for a multicasttransmission specifies the module identifiers which correlate with thepromotion content to be received. Furthermore, multicast start times,duration of the multicast transmission, and an IP multicast address andUDP port number may be specified. Alternatively, the start time may bereplaced with a trigger event initiating the reception of a multicasttransmission.

In step 840, the promotion agent 310 delivers the promotion downloadrequest messages to the bulk data agent 320 which maintains theresponsibility for selectively receiving subsets of promotions frommulticast transmissions as specified.

In step 850, the promotion manager server 220 generates transmissionrequests for each of the selected promotion packages. In brief overview,a transmission request contains module identifiers that correspond tothe actual promotion content being delivered as well as datatransmission parameters controlling the time and/or manner in which theset of promotions are to be transmitted. Such parameters extracted fromthe package may include data transmission rate, multicast IP address andport number, and number of transmission repeat cycles. The generation oftransmission requests is discussed in more detail with reference to FIG.8.

In step 860, the promotion manager server 220 sends the transmissionrequests as messages to a bulk data server 230. In a preferredembodiment, the promotion manager server 220 may send the sametransmission request to multiple bulk data servers located at the headends of the multimedia network providing additional scalability.

In step 870, the bulk data server 230 obtains the promotions from thedatabase 210 by the module identifiers specified in the transmissionrequests. Promotion content is transferred from the database 210 to abulk data cache local to the bulk data server.

The size of the local bulk data cache varies in time based on the sizeand number of promotions identified in the transmission requestsreceived from the promotion manager server 220. The amount of memoryallocated for the cache increases with the number and size of promotioncontent identified in a transmission request. As promotion packagesexpire (e.g., time for promotion activation has ended), stored promotioncontent is flushed (e.g. deleted) from the cache and memory isdeallocated from the cache; thus reducing the overall cache size.

In step 880, the bulk data agent 320 “tunes” into the multicasttransmission at the specified data transmission time or in response to aspecified trigger event. The bulk data agent 320 “tunes” into themulticast transmission by opening a connection to the IP multicastaddress and port.

In step 890, the bulk data server opens a multicast transmission sendingthe promotions to the IP multicast port address.

In step 895, the bulk data agent selectively receives the subset ofpromotions in the transmission and caches the promotions in its localdevice cache. In selectively receiving the promotions, the bulk dataagent 320 scans the multicast data stream for the module identifierscorresponding to the subset of promotions specified in the remotemonikers extracted from the promotion download request messages.

For subnetworks or devices that do not support IP multicast, the bulkdata transmission is performed through an IP broadcast. Althoughbroadcast transmissions of promotions would be sent to all devices, onlythose devices that have received transmission schedules will selectivelyreceive the promotions from the data stream.

Once the promotions have been successfully installed, promotions may beactivated at specified times or events indicated in the transmissionschedules.

Scheduling Packages

In more detail regarding the generation of transmission schedules andtransmission requests, the promotion scheduling process occurs in twointerleaved phases with the promotion manager server 220 cyclicallyprocessing packages extracted from the database 210. The first phaseinvolves the generation of transmission schedules and transmissionrequests from promotion packages. Transmission schedules andtransmission requests are then utilized in the second phase of thedelivery process for synchronizing bulk data transfers of promotionpackages discussed previously. Transmission schedules are distributed toend node devices 300 of targeted promotion groups notifying them inadvance of subsequent bulk data transfers, while transmission requestsare delivered to bulk data servers 230 to initiate the transfers.

In brief overview, the generation of transmission schedules involves thepromotion manager server 220 (1) extracting a set of packages from thedatabase 210; (2) generating a map of device transmission schedules fromthe extracted packages; (3) iterating through the map of devicetransmission schedules generating individual schedule messages for eachdevice; and (4) transmitting the individual schedule messages to eachdevice in the map using standard messaging.

In more detail, FIG. 7 is a flow diagram illustrating a process forgenerating transmission schedules for devices according to oneembodiment.

In step 2000, the promotion manager server 220 extracts a set ofpackages that have not been processed for schedule distribution.According to one embodiment, a package indicates that it has not beenprocessed for schedule distribution by setting its boolean INFO_TX_SENTparameter to false. Furthermore, the current system time should bewithin a specified range of the package's schedule transmission time(i.e., INFO_TX_TIME) for the package to be extracted. In one embodiment,the specified range is determined by the following:(INFO _(—) TX_TIME−ΔTproc/2)≦Tsys≦(INFO _(—) TX_TIME+ΔTproc/2)   (1)

where ΔTproc is the amount of time needed to process a maximum number ofpackages and Tsys is the current system time.

Packages may be extracted at a variable polling rate. Limits may beconfigured relating to the minimum and maximum poll frequencies.However, the exact value of the polling rate at a given time iscontrolled by the promotion manager server 220 itself based on thecurrent package load. As the number of packages processed per cycleremains constant or increases, the current polling rate decreases towardthe minimum poll frequency value at configurable increments. Conversely,as the number of packages decreases, the polling rate increases towardthe maximum poll frequency value at configurable increments.

Furthermore, the promotion manager server 220 maintains internalinformation relating to its own performance, specifically the rate atwhich packages are being processed. The host system on which a promotionmanager server 220 executes indirectly affects the efficiency of thescheduling process. As the number of processes on the system changes,the physical resources made available to the promotion manager server220 by the operating system vary. When the promotion manager server 220has fewer resources, the average package-processing rate will increase.When the promotion manager server 220 has more resources, this timedecreases.

In step 2010, after extracting the packages, the promotion managerserver 220 serially processes the set of packages selecting a package inorder of earliest package start time and extracting a set of promotionidentifiers from the selected package.

In step 2020, the promotion manager server 220 selects one of thepromotion identifiers and obtains a list of device identifiersrepresenting actual end node devices that are targeted for thepromotion.

In step 2030, the promotion manager server 220 generates a transmissionschedule for each device identifier adding a schedule entry for theselected promotion. Each schedule entry contains promotion control datawhich identifies the promotion, transmission parameters, and activationcriteria. According to one embodiment, transmission schedules aregenerated in memory as a stack of data objects representing multipleschedule entries generated from records within various tables of thedatabase 210.

In more detail, the promotion is identified in a schedule entry by itsmodule identifier. The module identifier corresponds to the promotioncontent stored in the database 210 and is associated with the promotionidentifier. It is possible that multiple promotion identifiers may beassociated with the same module identifier. The module identifier isused by the bulk data agent 320 of an end node device during a bulk datatransmission to selectively receive promotion content in the datastream.

The transmission parameters identified in the schedule entry areobtained from the data transmission parameters of the selected package.According to one embodiment, the transmission parameters in the scheduleentry may include a package transmission start time, the duration of thetransmission, and IP multicast address and port number. Alternatively,the package transmission start time may be replaced with a trigger eventsimilar to those for promotion activation. This information is used bythe bulk data agent to receive the multicast transmission.

The activation criteria specified in the schedule entry is obtained fromtime slot records stored in the database 210 that are associated withthe promotion identifiers. In general, the schedule entry specifies anactivation trigger event for the promotion and the duration of thepromotion. In particular, an activation trigger event may include astart time, a start message from the promotion manager server 220, thecapture of ATVEF tag in the video blanking interval during a programbroadcast, a channel change event, or a power event (e.g., OFF/ON).

In step 2040, the promotion manager server 220 determines whether thereare more promotions to process for this package. If so, the processreturns to step 2020 to select another promotion identifier from thepackage.

Otherwise, in step 2050, the promotion manager server 220 determineswhether there are more packages to process. If so, the process returnsto step 2010 to select the next package from the extracted set.

As processing proceeds to subsequent packages, additional scheduleentries are added to previously existing transmission schedules. If atransmission schedule has not been created for a device, then a newtransmission schedule is created and the schedule entry added. After thelast package has been processed, the promotion manager has an map ofdevice specific transmission schedules, keyed by device identifier.

After all of the packages have been processed, the promotion managerserver 220 iterates through the map of device transmission schedulesserializing each one. Serializing transforms the stack of data objectsinto binary serial data that may be transmitted in the payloads oftransmission schedule messages. Due to the fixed payload size of amessage, more than one schedule message may be required to deliver theentire transmission schedule to a device. The schedule messages are sentwith an expiration time such that the delivery time is limited. In thecase of message delivery failure where the delivery time expires with nomessage acknowledgment from a device, transmission errors are reportedin an error queue, and error information is captured in the database aswell. The promotion manager server 220 may then retransmit the schedulemessage. As schedule message deliveries proceed, the INFO_TX_SENT flagin each package is set to true and the schedule distribution processconcludes.

Upon reception at an end node device, the promotion agent regeneratesthe stack of data objects by de-serializes it into memory where it isused to drive the promotion reception and delivery process on thedevice.

Once the transmission schedules have been delivered, transmissionrequests are generated to initiate the scheduled transmissions from bulkdata servers located at the data center or head ends of a multimedianetwork. In brief overview, the generation of transmission requestsinvolves the promotion manager server 220 (1) extracting a set ofpackages from the database 210; (2) generating an individualtransmission request for each of the extracted packages; and (3)transmitting the transmission request to a bulk data server usingstandard messaging.

In more detail, FIG. 8 is a flow diagram illustrating a process ofgenerating transmission requests according to one embodiment.

In step 3000, the promotion manager server 220 extracts a set ofpackages whose transmission schedules have been distributed but have notbeen processed for data transmission. The extraction of the set ofpackages for data transmission may occur simultaneously with theextraction of packages for transmission schedule distribution. However,once extracted, packages are processed serially in order of earliestpackage start time, with data transmissions taking priority overschedule transmissions.

According to one embodiment, a package indicates that its promotionshave not been delivered by setting its boolean DATA_TX_SENT parameter tofalse. Furthermore, the current system time should be within a specifiedrange of the package's data transmission time (i.e., DATA_TX_TIME) for apackage to be extracted. The specified range may be determined by thefollowing:(DATA_(—) TX_TIME−ΔTproc/2)≦T system≦(DATA_(—) TX_TIME+ΔTproc/2)   (2)

where ΔTproc is the amount of time needed to process a maximum number ofpackages and Tsys is the current system time.

In step 3010, after extracting the packages, the promotion managerserver 220 serially processes the set of packages selecting a package inorder of earliest package start time and extracting the datatransmission parameters from the package. Each package contains all ofthe parameters needed to initiate a multicast data transmission. Suchparameters include the transmission start time, the duration of thetransmission, the data transmission rate, and the IP multicast addressand port.

In step 3020, the promotion manager server 220 creates a transmissionrequest object for the package containing the extracted datatransmission parameters. These parameters control the time and manner oftransmitting the packages.

In step 3030, the promotion manager server 220 extracts the set ofpromotion identifiers from the package and resolves them into theassociated module identifiers that correspond to the actual promotioncontent stored in the database 210.

In step 3040, the promotion manager server 220 adds each of the moduleidentifiers to the transmission request object. FIG. 9 is a tableillustrating the parameters of a transmission request according to oneembodiment.

In step 3050, the promotion manager server 220 determines which bulkdata servers 320 are to transmit promotion packages and thus receive thetransmission request. According to one embodiment, the promotion managerserver 220 resolves each package into a list of the network identifiersthat need to multicast the data. The list of network identifiers isdistilled from the list of promotion recipients (i.e., deviceidentifiers). From the network identifiers, a message router 250-nservicing each network identifier is determined. Transmission requestmessages are then sent to each of the bulk data servers 230 thatservices head end networks 50 via the message routers.

In step 3060, the promotion manager server 220 serializes thetransmission request object and sends it in the payload of messages tothe appropriate bulk data servers that will handle the bulk datatransfers of the identified promotion content as specified.

FIGS. 10A-10F illustrate the organization of the tables of recordswithin the database 210 according to one embodiment. The solid anddotted lines illustrate the interrelations among various records. Forexample according to one embodiment, T_PACKAGE 910 is database recordwithin a table of other T_PACKAGEs implementing a package. The packageis adapted for the common attributes of a transmission group through aparameter which references the group identifier for a particulartransmission group (i.e. TRANSMISSION_GROUP_ID). This identifier is usedto index into a table of T_TRANSMISSION_GROUP records 920 that specifyparameters for data transmission, such as maximum storage threshold anddata transmission rates, to the member devices of the transmissiongroup, such as a particular class of set top boxes.

While this invention has been particularly shown and described withreferences to preferred embodiments thereof, it will be understood bythose skilled in the art that various changes in form and details may bemade therein without departing from the scope of the inventionencompassed by the appended claims.

1. A method of packaging promotions for transmission over a multimedianetwork, comprising: associating a promotion group with at least onepromotion, the promotion group comprising viewers associated withpromotion; identifying end node devices associated with the promotiongroup; subdividing the end node devices of the promotion group into aplurality of transmission groups, each of the transmission groupscomprising a plurality of end node devices with at least one commonphysical attribute; and creating a package for each of the transmissiongroups, each package adapted to accommodate the common physicalattributes of the specific transmission group to which it relates. 2.The method of packaging promotions of claim 1, further comprising:sending packages to at least one transmission group via a broadcast ormulticast transmission.
 3. The method of packaging promotions of claim1, wherein the common physical attribute comprises device data storagecapacity.
 4. The method of packaging promotions of claim 3, wherein eachpackage specifies a maximum package size, the maximum package size ofeach package being less than or equal to a device data storage capacityof a corresponding transmission group.
 5. The method of packagingpromotions of claim 4, additionally comprising: adding promotions to apackage unless the maximum package size is reached; creating a newpackage when the maximum package size for the package is reached; andadding the remaining promotions from the set of promotions to the newpackage.
 6. The method of packaging promotions of claim 4, furthercomprising: deassociating the promotion group from the set ofpromotions; and removing the set of promotions from each package suchthat a size of the package is reduced.
 7. The method of packagingpromotions of claim 3, wherein the device data storage capacity is anexpected amount or percentage of available device storage for cachingpromotions.
 8. The method of packaging promotions of claim 3, whereinthe device data storage capacity is an expected amount or percentage ofdedicated device storage for caching promotions.
 9. The method ofpackaging promotions of claim 1, wherein the common physical attributecomprises device processor speed.
 10. The method of packaging promotionsof claim 3, wherein the common physical attribute is data communicationrate.
 11. The method of packaging promotions of claim 1, wherein theplurality of end node devices are set top boxes capable of activatingpromotions in a television environment.
 12. The method of packagingpromotions of claim 1, further comprising: sending packages totransmission groups via separate broadcast or multicast transmissionsdirected to the transmission groups.
 13. A system for packagingpromotions for transmission groups, comprising: a promotion managerserver; a promotion storage device for storing a plurality ofpromotions; the promotion manager server defining a promotion groupwhich is to receive a promotion, the promotion group comprising end nodedevices targeted to receive a promotion; subdividing the end nodedevices of the promotion group into transmission groups, each of thetransmission groups comprising a plurality of end node devices having atleast one common physical attribute; creating a package for each of thetransmission groups, each package adapted to accommodate the commonphysical attribute of the transmission group to which it relates. 14.The system for packaging promotions of claim 13, further comprising: abulk data server for sending packages comprising a plurality of end nodedevices having at least one common physical attribute via separatebroadcast or multicast transmissions directed to the transmissiongroups.